На днях компания VMware (помимо анонса серверной платформы vSphere 6.7 Update 2) анонсировала и скорую доступность продукта VMware vRealize Operations 7.5, предназначенного для комплексного управления и мониторинга виртуальной инфраструктуры. Напомним, что о прошлой версии этого решения - vROPs 7.0 - мы писали вот тут. Давайте посмотрим, что нового появилось в vROPs версии 7.5.

1. Улучшения механики оптимизации производительности.

Основное улучшение в этой категории заключается в новом механизме по оптимизации инфраструктуры отказоустойчивых кластеров хранилищ vSAN. Движок vROPs теперь предлагает оптимизации с учетом знаний о процессах синхронизации/ресинхронизации, мониторинга свободного пространства и действующих политиках хранилищ.

После анализа кластеров vSAN администратор может выбрать ручной режим оптимизации, запланировать ее на конкретное время, либо запустить оптимизацию в автоматическом режиме и смотреть, какие именно операции выполняются в фоновом режиме.

2. Улучшения механизма управления емкостями датацентра.

Здесь произошел возврат к модели выделенных ресурсов (allocation) взамен модели потребляемых ресурсов (demand). Последняя оказалась эффективной только для небольших инфраструктур, а планирование больших датацентров лучше делать по номинальным значениям аппаратных запросов ВМ.

При этом для администратора на дэшборде Capacity параметры Allocation и Demand приведены рядом:

Помимо этого, для виртуальных машин можно задавать кастомные профили, чтобы более точно рассчитывать емкости в различных сценариях (см. выше).

Еще одна полезная функция vROPs 7.5 - возможность обнаруживать бесхозные VMDK-диски, болтающиеся отдельно от виртуальных машин. У этих дисков, по крайней мере, можно вернуть выделенное место с нулевыми блоками в сторону дискового массива, что даст вам еще некоторое количество свободного места.

Также в этой категории фичей особо можно отметить комплексную и глубокую "what-if" аналитику, которая позволяет планировать, в том числе, гиперконвергентную инфраструктуру, а также миграции рабочих нагрузок в облака AWS, Azure и другие:

Особо нужно отметить возможность сравнения стоимости содержания онпремизной инфраструктуры в собственном датацентре с облачными инфраструктурами Amazon, Google и другими в виде карточек:

3. Функции интеллектуального исправления конфигураций виртуальной инфраструктуры.

Здесь появилась важная новая возможность - мониторинг ОС и приложений внутри виртуальных машин. Это дает много новых инструментов для изучения поведения и производительности инфраструктуры со стороны приложений.

vROPs автоматически обнаруживает приложения в вашей виртуальной инфраструктуре и добавляет их к себе в консоль. Далее администратор может решить - стоит ли их мониторить здесь в vROPs или нужно передать их на сторону решения Wavefront от VMware, заточенного под эти задачи.

Оба этих метода мониторинга используют агенты Telegraf для сбора метрик и отчетности:

В vROPs 7.5 появилось новое представление - виджет отношений объектов. Он показывает высокоуровневую связь приложения с компонентами датацентра. В рамках этого представления можно понять, связана ли проблема с самим приложением, или она вызвана нижележащими компонентами инфраструктуры. В рамках одного представления поддерживается до 10 000 объектов:

Также теперь появилась возможность построить графики корреляции метрик различного характера для этих объектов, чтобы выявить корень проблемы низкой производительности на различных уровнях:

Ну и последняя, но очень важная новая фича в этой категории - двунаправленная интеграция с ServiceNow, что позволяет встроить vROPs и его метрики в рабочие процессы системы ServiceNow.

4. Интегрированный комплаенс.

Это новое направление функционала vROPs. Оно подразумевает выполнение процедур по обеспечению соответствия таким отраслевым стандартам, как PCI, HIPAA, DISA, ISO, CIS и FISMA. Помимо готовых шаблонов, вы сможете использовать кастомные наборы политик, для которых можно проводить приведение инфраструктуры в соответствие и мониторинг отклонений от заданного уровня. Для всего этого уже из коробки есть готовые рабочие процессы (Workflows) и интеграция с решением VMware vRealize Orchestrator.

Также надо отметить, что vROPs без проблем может мониторить облачную инфраструктуру VMware Cloud on AWS - для него это всего лишь еще один экземпляр окружения vCenter.

На данный момент продукт VMware vRealize Operations 7.5 еще недоступен для загрузки, новости можно отслеживать на его основной странице.

На днях компания VMware анонсировала доступность новой версии своей флагманской платформы виртуализации VMware vSphere 6.7 Update 2. Напомним, что предыдущее обновление VMware vSphere 6.7 Update 1 вышло в августе прошлого года.

Давайте посмотрим, что с тех появилось нового:

1. Новое издание VMware vSphere ROBO Enterprise.

Теперь в издании для ROBO-сценариев (Remote or Branch Offices) появились следующие возможности уровня Enterprise:

DRS в режиме обслуживания (Maintenance Mode):

• Доступно только для vSphere ROBO Enterprise.
• Может быть использовано для автоматического перемещения ВМ между хостами (и обратно по окончании процесса). Для этого автоматически создаются правила VM-Host affinity (отслеживается, куда машины уехали перед миграцией, потом запомненные правила применяются - и машины приезжают обратно, где и были изначально).
• Применяются обычные требования vMotion.
• Никакого визуального механизма настройки DRS нет.

Шифрование машин (VM Encryption):

• Шифрование домашней директории и файлов VMDK.
• Требуется инфраструктура KMS.
• Полностью безразлично к гостевой ОС.
• Управляется через GUI или PowerCLI.

2. Обновление архитектуры vCenter Server.

Утилита PSC Converge tool теперь доступна в графическом интерфейсе. Об этом средстве мы писали вот тут, оно позволяет смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC.

Она дает следующие возможности:

• Конвертация топологии external PSC в Embedded через GUI.
• Можно выполнить шаги по выводу внешнего PSC из эксплуатации (Decomission).

• Все это доступно в разделе System Configuration тонкого клиента vSphere Client (на базе HTML5).
• Можно посмотреть текущую топологию PSC и vCenter в графическом или табличном виде.
• В следующих релизах будет невозможно развернуть внешний PSC, поэтому с него надо уходить.

3. Улучшения резервного копирования и восстановления vCenter Server.

Здесь появилось 2 главных улучшения:

• Новые протоколы, посредством которых вы можете сделать бэкап vCSA - NFS v3 и SMB.
• Нотификации и алармы на успешное и неуспешное завершение задач РК. Эти алармы можно настроить подобно обычным алармам vSphere (послать email, SNMP trap или выполнить сценарий в случае успеха или неудачи).

4. Новые алармы и категории для vSphere Health.

• Опция acknowledgement (заглушить) для алармов vSphere health (как и для обычных алармов).
• Новые категории теперь включают в себя:
  • Online Availability
  • Compute
  • Network
  • Storage
• Эти новые категории позволяют более органично охватывать проблемы сервера vCenter и упрощать управление им.

5. Улучшения Content Library.

• Функции синхронизации шаблонов VM Template (VMTX).
• Шаблоны виртуальных машин теперь можно синхронизировать в автоматическом режиме, как между приватными облаками с серверами vCenter, так и с публичным облаком VMware Cloud on AWS.

6. Улучшения vSphere Client.

• В vSphere Client появилась возможность "code capture" (о ней мы писали вот тут). Теперь она позволяет вести запись пользовательских действий, которые были сделаны в рамках текущей сессии через vCenter API, и генерация соответствующего скрипта. Далее его можно использовать для автоматизации задач в инфраструктуре vSphere.
• Функции API Explorer (доступны в разделе "Developer Center") - простая утилита по поиску в API, которая позволяет найти основные API-вызовы, включая примеры и возможность их тестирования.

• Улучшения пользовательского интерфейса, включая функции attach, compliance check и remediation (все можно делать на одном экране).
• Теперь можно привязать и сделать remediate для нескольких бейслайнов в рамках одной операции.
• Во время remediation можно отключать removable-девайсы от виртуальных машин, включать Quickboot и пропускать проверки vSAN HealthCheck.

8. Улучшения VMware Tools.

• Для Windows Server 2016 тулзы теперь обновляются через Windows update, а значит, что их обновления включены в общий цикл апдейта системы.
• Версия VMware tools for Linux (в формате .TAR) больше не развивается, начиная с VMware Tools 10.3.10, так как OpenVM Tools доступны через любой package update manager.

9. Фикс Host Profiles.

Теперь при применении профиля хоста к ESXi не удаляется интерфейс VMK0, как это было раньше.

10. Улучшения безопасности.

• Windows Server 2019 и RHEL 8 теперь полностью поддерживаются в vSphere 6.7 Update 2.
• Можно применять лимиты для Password History и Reuse.
• Теперь логируются дополнительные события SSO.
• Улучшения ESXi certification API.
• Генерация запроса vCenter Server CSR доступна через GUI клиента.
• vSphere 6.7 Update 2 лучше обрабатывает уязвимости CPU за счет нового планировщика.
• Доступна сертификация NIAP.

11. Улучшения производительности.

• Поддержка 40 & 100Gb Ethernet и RDMA
• Новая версия Virtual Hardware 15 (VM Compatibility):
  • До 256 vCPU на виртуальную машину
  • До 6 ТБ RAM на ВМ
  • Поддержка SAP HANA

На момент написания статьи обновление VMware vSphere 6.7 Update 2 было еще недоступно. Мы обновим пост, когда обновление можно будет скачать.

Интересный проект доступен на GitHub - набор скриптов vDocumentation, который позволяет через PowerCLI сгенерировать отчетность в форматах CSV или XLS, посвященную различным сторонам виртуальной инфраструктуры (сеть, хосты, кластеры vSAN и т.п.). Демо этого средства было представлено на VMworld 2017:

Проект vDocumentation на текущий момент содержит 8 сценариев, каждый из который позволяет подготовить соответствующий отчет:

• Get-ESXInventory - генерация всех аппаратных параметров хостов ESXi и их конфигураций.
• Get-ESXIODevice - документирование конфигурации карт HBA, NIC и других PCIe-устройств, включая PCI ID, MAC, версии микрокода и драйверов.
• Get-ESXNetworking - конфигурация сетевого окружения, включая детали сетевых адаптеров, коммутаторов vSwitches, параметры VMKernel и прочее.
• Get-ESXStorage - параметры инфраструктуры хранилищ, включая детали iSCSI, FibreChannel, параметры датасторов и механизма доступа по нескольким путям (Multipathing).
• Get-ESXPatching - информация об установленных обновлениях, времени их выхода и ссылки на соответствующие статьи KB.
• Get-vSANInfo - документирование кластеров vSAN.
• Get-ESXSpeculativeExecution - статус серверов ESXi в отношении уязвимостей Spectre и Meltdown.
• Get-VMSpeculativeExecution - статус виртуальных машин в отношении уязвимостей Spectre и Meltdown.

Например, вот отчет о статусе хостов ESXi в отношении уязвимостей Spectre и Meltdown:

По умолчанию данные выводятся в терминал, но можно их перенаправить с CSV или XLS файлы.

Загрузить сценарии vDocumentation можно по этой ссылке.

Компания VMware недавно выпустила интересный постер, посвященный облачной IaaS-инфраструктуре, предоставляемой в партнерстве с Amazon - VMware Cloud on AWS - Quick Reference.

Постер дает информацию о различных типах соединений, которые доступны в облаке VMConAWS:

Плакат разделен на 5 секций, заголовки у которых кликабельны - по ссылкам находится детальная информация по соответствующей теме (кроме секции Firewall Rules, где кликабельны подзаголовки).

Содержимое разделов:

1. Infrastructure Overview - высокоуровневая диаграмма, показывающая отношения между онпремизным датацентром, инфраструктурой VMware Cloud on AWS SDDC и нативными сервисами AWS.
2. HCX Enterprise Network - детальная диаграмма, раскрывающая суть компонентов HCX, соединения, потоки и порты, используемые между онпремизным датацентром и облаком VMware Cloud on AWS.
3. Direct Connect Topology - эта секция показывает компоненты и общую топологию использования технологии AWS Direct Connect (DX) для организации соединения между онпремизным датацентром и облаком VMware Cloud on AWS.
4. NSX-T AWS Connected VPC - эта диаграмма показывает, каким образом организуется коммуникация между виртуальным частным облаком VMware Cloud on AWS VPC (Virtual Private Cloud) и пользовательским соединением VPC, в случае если используются родные сервисы AWS.
5. Firewall Rules - последняя секция включает список самых часто используемых правил сетевого экрана, используемых между онпремизным датацентром и облаком VMware Cloud on AWS для компонентов Management Gateway, HCX и Site Recovery.

Постер VMware Cloud on AWS - Quick Reference доступен по этой короткой ссылке. Напомним также, что все постеры VMware находятся здесь.

В марте прошлого года мы писали о выпуске пакета RVTools 3.10, предназначенного для помощи администраторам при выполнении рутинных операций с виртуальной инфраструктурой VMware vSphere в различных аспектах. Спустя год, в начале марта этого года, вышло обновление этого средства - RVTools 3.11 (а точнее, его версия 3.11.6).

Давайте посмотрим, что нового в RVTools 3.11:

• Теперь для управления используется обновленный VMware vSphere Management SDK 6.7U1.
• Windows Authentication Framework (Waffle) больше не используется.
• Библиотека NPOI .NET больше не используется для генерации отчетов в Excel. Вместо этого используются компоненты OpenXML и ClosedXML.
• Как следствие прошлого пункта - улучшения производительности при экспорте данных в Excel.
• Добавлены параметры -ExcludeCustomAnnotations и –DBColumnNames в интерфейс CLI.
• На вкладке vInfo добавлены новые колонки: дата создания ВМ, Primary IP, контрольная сумма vmx-файла, папки с логами ВМ, ее снапшотами и suspend-файлами.
• На вкладке dvSwitch добавлены новые колонки: имя LACP, его режим и алгоритм балансировки.
• На вкладке vNIC добавлена колонка с именем порта аплинка.
• На вкладке vNetwork добавлена колонка Network Adapter DirectPath I/O.
• На вкладке vHost появились колонки Serial number и BIOS vendor.
• При экспорте в Excel шапка таблицы теперь закреплена.
• Первая колонка "Select" убрана из таблиц экспорта для vFloppy, vCD и vTools.
• Добавлен новый экзешник для слияния нескольких файлов xlsx для серверов vCenter в один большой:
  • RVToolsMergeExcelFiles.exe -input c:\temp\AA.xlsx;c:\temp\BB.xlsx -output
c:\temp\AABB.xlsx -template c:\temp\mytemplate.xlsx -verbose –overwrite
• Сценарий примера RVToolsBatchMultipleVCs.ps1 изменился, он теперь как раз использует утилиту RVToolsMergeExcelFiles из предыдущего пункта для слияния файлов.
• Исправлены ошибки:
  • Проблема с SSO
  • Команды ExportvSC+VMK2csv и ExportdvPort2csv теперь работают
  • На вкладке vNIC теперь отображается вся информация для Switch/dvSwitch
  • При экспорте учитывается значение Latency Sensitivity
  • Улучшено обновление данных при изменении настроек
  • Файлы VMDK из Content Libraries теперь не отображаются как "зомби-файлы"

Скачать утилиту RVTools 3.11 можно совершенно бесплатно по этой ссылке. Документация доступна здесь.

Совсем недавно мы писали о новых возможностях решения VMware NSX-T 2.4, которое предназначено для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений.

Также у VMware есть продукт vRealize Network Insight, который позволяет системным и сетевым администраторам, а также администраторам информационной безопасности, следить за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

Ну и, конечно же, многие из вас помнят решение AppDefense, анонсированное на VMworld 2017. Оно реализует новую модель защиты приложений в виртуализованных и облачных средах. Суть технологии AppDefense заключается в том, что она изучает нормальное поведение операционной системы и приложений при обычных условиях, а в случае выявления отклонений от этого состояния, оповещает об этом администратора и автоматически предпринимает некоторые шаги по защите окружения.

Использовав наработки этих трех продуктов за последние годы, компания VMware на днях анонсировала новое решение - первый в отрасли Service-defined Firewall.

Это решение основано на подходе по микросегментации приложений с точки зрения защиты виртуальной среды (см. service insertion и guest introspection), что подразумевает анализ сетевой активности на уровне приложения, при этом мониторинг ведется извне гостевой ОС на уровне гипервизора (данные берутся из NSX или напрямую с серверов ESXi), что позволяет исключить манипуляции средствами обнаружения вторжений, которые могут быть выполнены программным обеспечением внутри ОС.

Но главная штука VMware Service-defined Firewall - это возможность создания политик на уровне приложений/микросервисов, а не сетевых компонентов (серверов/ОС/портов). Это существенно упрощает ввод в эксплуатацию новых сервисов с точки зрения организации их защиты, а также обслуживания при перемещении виртуальных машин внутри датацентра и между ЦОДами.

Традиционная защита ИТ-инфраструктуры строится на базе обеспечения безопасности приложений, находящимися за сетевыми экранами, то есть защищается только сетевой периметр. При этом часто вектор атаки расположен внутри инфраструктуры, где вредоносное ПО сначала изучает ее состав и структуру, а потом начинает распространяться в датацентре, используя его уязвимые места.

VMware Service-defined Firewall позволит использовать новый подход к защите сетевой инфраструктуры предприятия за счет анализа приложений внутри периметра ЦОД (internal network firewalling), где наблюдение за сервисами происходит на уровне гипервизора и на седьмом уровне модели OSI (L7 packet inspection), без агентов в гостевых ОС, при этом используется модель Zero Trust (то есть изначально нет доверия ни одному компоненту в сети, считается, что атака может прийти откуда угодно, через любое сетевое соединение).

Суть защиты заключается в наблюдении за всеми приложениями датацентра, определении их "хорошего" поведения и далее детектировании отклонений от их повседневной активности, что влечет за собой оповещение администратора, который уже предпринимает действия по устранению угроз. При этом VMware Service-defined Firewall сам способен сгенерировать нужные политики для защиты приложений.

Такая модель обладает неоспоримым преимуществом перед системами с агентами, где вредоносное ПО может получить контроль над этими агентами. Также еще один плюс VMware Service-defined Firewall - это чисто программная реализация. В современном мире программно-аппаратные сетевые экраны сложно масштабируются, а также есть проблемы с управлением ими, так как приложение в виртуальной инфраструктуре может перемещаться между серверами и даже между датацентрами.

Для анализа подозрительных активностей используется Application Verification Cloud, который собирает информацию из миллионов виртуальных машин по всему миру и использует методы машинного обучения для определения нормального поведения микросервисов и их вариаций, а также выявления отклонений от нормальных показателей.

Что интересного можно почитать на тему VMware Service-defined Firewall:

• Основная страница VMware Service-defined Firewall
• Отчет Validation Report of the Service-Defined Firewall by Verodin
• Лабораторная работа VMware NSX Micro-Segmentation Hands-on Lab
• Документ Enabling Zero Trust Security Through Network Virtualization And MicroSegmentation
• Статья Micro-segmentation with Service Insertion
• YouTube-канал о VMware NSX

Видео про возможности NSX-T 2.4, которые будут использованы в Service-defined Firewall:

Service-defined Firewall в действии и консоль AppDefense:

Многие из вас знают, что у компании StarWind есть продукт Virtual SAN для построения программных отказоустойчивых хранилищ, являющийся на сегодняшний день одним из лидеров отрасли. Но самое интересное, что у StarWind есть и программно-аппаратный комплекс HyperConverged Appliance (HCA), на базе которого можно строить недорогую инфраструктуру виртуализации и хранения для небольших компаний (а также для сценариев ROBO - remote or brunch offices, то есть филиалов).

Вы все, конечно же, в курсе, что графические карты уже давно используются не только для просчета графики в играх и требовательных к графике приложениях, но и для вычислительных задач. Сегодня процессоры GPGPU (General Purpose GPU) используются в ИТ-инфраструктурах High Performance Computing (HPC) для решения сложных задач, в том числе машинного обучения (Machine Learning, ML), глубокого обучения (Deep Learning, DL) и искусственного интеллекта (Artificial Intelligence, AI).

Эти задачи, зачастую, хорошо параллелятся, а архитектура GPU (по сравнению с CPU) лучше приспособлена именно для такого рода задач, так как в графических платах сейчас значительно больше вычислительных ядер:

Кроме того, архитектура CPU больше заточена на решение последовательных задач, где параметры рассчитываются друг за другом, а архитектура GPU позволяет независимо просчитывать компоненты задачи на разных процессорных кластерах, после чего сводить итоговый результат.

Вот так, если обобщить, выглядит архитектура CPU - два уровня кэша на базе каждого из ядер и общий L3-кэш для шаринга данных между ядрами:

Число ядер на CPU может достигать 32, каждое из которых работает на частоте до 3.8 ГГц в турбо-режиме.

Графическая карта имеет, как правило, только один уровень кэша на уровне вычислительных модулей, объединенных в мультипроцессоры (Streaming Multiprocessors, SM), которые, в свою очередь, объединяются в процессорные кластеры:

Также в видеокарте есть L2-кэш, который является общим для всех процессорных кластеров. Набор процессорных кластеров, имеющих собственный контроллер памяти и общую память GDDR-5 называется устройство GPU (GPU Device). Как видно, архитектура GPU имеет меньше уровней кэша (вместо транзисторов кэша на плату помещаются вычислительные блоки) и более толерантна к задержкам получения данных из памяти, что делает ее более пригодной к параллельным вычислениям, где задача локализуется на уровне отдельного вычислительного модуля.

Например, если говорить об устройствах NVIDIA, то модель Tesla V100 содержит 80 мультипроцессоров (SM), каждый из которых содержит 64 ядра, что дает в сумме 5120 ядер! Очевидно, что именно такие штуки надо использовать для задач ML/DL/AI.

Платформа VMware vSphere поддерживает технологию vGPU для реализации такого рода задач и возможности использования виртуальными машинами выделенных ВМ модулей GPU. В первую очередь, это все работает для карточек NVIDIA GRID, но и для AMD VMware также сделала поддержку, начиная с Horizon 7 (хотя и далеко не в полном объеме).

Если говорить о задачах машинного обучения, то мы уже писали о результатах тестирования Machine Learning/Deep Learning задач на платформе VMware vSphere. Все это уже сейчас используется в здравоохранении, страховании, финансах и других отраслях.

Еще одна интересная архитектура для решения подобных задач - это технология FlexDirect от компании BitFusion. Она позволяет организовать вычисления таким образом, что хосты ESXi с модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При CUDA-инструкции от клиентских ВМ передаются серверным по сети:

Обмен данными может быть организован как по TCP/IP, так и через интерфейс RDMA, который может быть организован как подключение Infiniband или RoCE (RDMA over Converged Ethernet). О результатах тестирования такого сетевого взаимодействия вы можете почитать тут.

При этом FlexDirect позволяет использовать ресурсы GPU как только одной машине, так и разделять его между несколькими. При этом администратор может выбрать, какой объем Shares выделить каждой из машин, то есть можно приоритизировать использование ресурсов GPU.

Такая архитектура позволяет разделить виртуальную инфраструктуру VMware vSphere на ярусы: кластер GPU, обсчитывающий данные, и кластер исполнения приложений пользователей, которые вводят данные в них и запускают расчеты. Это дает гибкость в обслуживании, управлении и масштабировании.

Более подробно о настройке FlexDirect написано здесь, а документация по продукту доступна тут.

Осенью 2017 года мы писали о релизе операционной системы VMware Photon OS 2.0, предназначенной для контейнеров Docker, cloud-native приложений, публичных облачных платформ и инфраструктуры VMware (виртуальные модули).

Оказывается, как справедливо отметили в комментариях, в конце февраля этого года было выпущено обновление VMware Photon OS 3.0. Давайте посмотрим, что там нового:

1. Поддержка архитектуры ARM64.

Теперь Photon OS 3.0 можно запускать на Raspberry Pi 3. Для этого есть предсобранный образ, а также возможность собирать новые образы с помощью image builder.

2. Улучшения установки.

• Теперь инсталлятор можно запускать с различных носителей, таких как USB, CDROM и средств kickstart с любого из поддерживаемых устройств хранения.
• Driver Development Kit - возможность интегрировать свои кастомные драйверы.

3. Прочие улучшения.

• Предсобранные образы для развертывания на облачных платформах Microsoft Azure, Google Compute Engine (GCE), Amazon Elastic Compute Cloud (EC2) и VMware (vSphere, Fusion и Workstation).
• Новые версии следующих базовых пакетов ОС:
  • Linux kernel 4.19
  • Glibc 2.28
  • systemd 239
  • Python3 3.7
  • Openjdk : 1.8.0.192
• Обновление большинства пакетов, доступных из репозитория (около 440 пакетов были обновлены).
• Возможность одновременной поддержки пакетов разных версий (например, go-1.9 и go-1.10).
• Новые пакеты: EdgeX, Liota, linux-firmware, wpa_supplicant for WLAN, consul, meson и другие.

Также в Photon OS 3.0 теперь доступно 3 размера установки ОС:

• Minimal - для IoT-устройств с самыми минимальными базовыми требованиями.
• Developer - пакеты для создания, тестирования и развертывания контейнеризованных приложений.
• Edge - включает пакеты для создания устройства edge gateway.

Скачать VMware Photon OS 3.0 можно по этой ссылке. Там же доступна и документация.

Летом прошлого года мы писали об обновлении утилиты для сотрудников технической поддержки, работающих с пользователями инфраструктуры VMware Horizon - Horizon Helpdesk Utility версии 1.2. Это решение реализует всю функциональность Helpdesk в HTML5 интерфейсе управления VMware Horizon, но поставляется теперь как отдельное решение с расширенными возможностями.

На днях на сайте проекта VMware Labs вышло существенное обновление этого средства - Horizon Helpdesk Utility 1.3. Давайте посмотрим, что там появилось нового:

• Убран вывод списка виртуальных машин из представления сессий.
• Улучшенное представление Environment view, которое включает метрики для всей подключенной инфраструктуры:
  • vSphere 
  • Hosts 
  • Datastores 
  • Удаленные объекты Pods 
  • Events 
  • Проблемные машины
• Добавлены повторяющиеся запросы для процедуры logon breakdown, если они были пропущены при первой попытке.
• Добавлена поддержка запросов к событиям при logon breakdown.
• Добавлен просмотр событий для фермы и пулов десктопов.
• Добавлен встроенный поиск пользователей и машин в представлении пулов.
• Добавлена функция множественного выбора в представлении пулов и фермы.
• Добавлены графики для машин и сессий, а также проблемные машины в разделе Environment overview.
• Добавлен pod switcher в Environment overview.
• Расширены функции Pod Jumping:
  • возможность по требованию перейти к нужному pod
  • возможность перейти к pod, к которому относится выбранная сессия
• Добавлена поддержка представления Architecture view для пулов десктопов и фермы.
• Добавлена пакетная поддержка пользовательских задач для пулов десктопов и фермы:
  • Отправление сообщений
  • Log off
  • Disconnect
  • Reset
  • Restart
• Поддержка представления local pod view (он же Environment view).
• Добавлена документация (можно выбрать в комбо-боксе загрузки утилиты).
• Добавлена поддержка MSI-инсталлятора.
• Добавлена колонка start time в представлении пользовательских сессий.

Скачать VMware Horizon Helpdesk Utility 1.3.3.1 можно по этой ссылке.

Многие администраторы VMware vSphere сталкиваются с необходимостью развертывания кастомных образов VMware ESXi, например, от HP или Dell, так как они содержат все необходимые драйверы серверного оборудования.

Но процедура, как правило, такова - сначала администратор развертывает последний доступный образ ESXi Custom ISO, а уже после установки накатывает на него обновления через ESXCLI или Update Manager. Это несколько неудобно, так как зачастую требует перезагрузки уже после окончания основной установки.

Если у вас, например, 1500 хостов ESXi, то дополнительное время которое вы потратите за год на процедуры обновления после основной установки может составить до 42 часов в месяц (при условии, что вы накатываете по каким-то причинам образ ESXi на сервер где-то раз в год). Это, конечно же, очень много, поэтому в таких случаях стоит задуматься об интеграции обновлений в кастомизированный образ ESXi.

На самом деле, делается это достаточно просто с помощью PowerCLI в несколько команд (подробно процесс описан в документе Image Builder Patching):

1. Загружаете патчи в формате zip-бандлов и складываете их в одну папку.

2. Добавляете файл образа в software depot:

Add-EsxSoftwareDepot .\update-from-esxi6.5-6.5_update02.zip

3. Получаем имя стандартного профиля образа командой:

Get-EsxImageProfile | fl *

4. Клонируем этот профиль, используя его имя, полученное на предыдущем шаге:

New-EsxImageProfile -CloneProfile “ESX-6.5.0-20180502001-standard” -Name MyCustomImage
-Vendor “Friendly Neighborhood TAM”

Также можно использовать команду выборки профиля по его номеру:

New-EsxImageProfile -CloneProfile (Get-EsxImageProfile |Select -Last 1).Name -Name
MyCustomImage -Vendor “Friendly Neighborhood TAM”

5. Добавляем файл обновления в software depot командой:

Add-EsxSoftwareDepot .\ESXi650-201810001.zip

6. Выводим список профилей ESXi и убеждаемся, что появились оба наших обновленных профиля (см. профили с датой обновления 9/27):

Get-EsxImageProfile

7. С помощью команд Get-EsxSoftwarePackage и (Get-EsxImageProfile MyCustomImage).viblist просматриваем состав пакета и vib-пакетов:

Get-EsxSoftwarePackage

(Get-EsxImageProfile MyCustomImage).viblist

Эта команда покажет только те vib-пакеты, которые были присоединены к кастомному образу:

8. Устанавливаем для текущего профиля самые новые компоненты, которые есть в нашем хранилище:

Set-EsxImageProfile MyCustomImage -SoftwarePackage (Get-EsxSoftwarePackage -Newest)

9. Экспортируем наш текущий обновленный образ в форматы ISO и zip:

Export-EsxImageProfile MyCustomImage -ExportToIso .\ESXi.6.5U2-Patched.iso

Export-EsxImageProfile MyCustomImage -ExportToBundle .\ESXi.6.5U2-Patched.zip

После этого данные файлы можно использовать для развертывания / обновления хостов ESXi.

Если процедура осталась неясна - читайте документ Image Builder Patching.

Очень дельную статью написал Вильям Лам, касающуюся настройки алармов для различных событий в инфраструктуре VMware vSphere. Иногда системному администратору требуется настроить мониторинг каких-либо действий пользователей, которые вызывают генерацию событий в консоли vSphere Client.

Например, вы хотите получать аларм, когда пользователь создает папку (Folder) для виртуального окружения через vSphere Client. Для начала нам понадобится информация, которую мы будем использовать в описании аларма. Для этого мы делаем действие, генерирующее событие, вручную (в данном случае, создаем папку), а после этого идем в раздел Monitor->Tasks, где смотрим описание задачи и связанного с ней события:

Главное здесь для нас - это лейбл "Task: Create folder", по которому мы найдем этот тип событий через PowerCLI, а точнее его Description Id. Открываем консоль PowerCLI и выполняем там вот такую команду, указав лейбл нашего события, найденный в консоли vSphere Client:

$createFolderEvents = Get-VIEvent | where {$_.GetType().Name -eq "TaskEvent" -and $_.FullFormattedMessage -eq "Task: Create folder" }
$createFolderEvents[0].Info.DescriptionId

Результатом будет Description Id нашего события - это Folder.createFolder:

Далее можно создавать аларм, зная Description Id события. Выбираем тип условия Task event, а также описание в виде Description Id, тип условия end with и сам этот ID - Folder.createFolder:

После создания такого аларма, при каждом создании папки он будет срабатывать, что можно увидеть в разделе Triggered Alarms:

Таким же образом вы можете настроить алармы и для любых других событий, происходящих в инфраструктуре VMware vSphere.

Политика ограничения виртуальных машин по операциям ввода-вывода (IOPS limits storage policy rule) позволяет ограничить виртуальную машину в кластере VMware vSAN в плане потребления ресурсов хранилища. Она применяется для VMDK дисков машин и, как правило, используется в ситуациях, когда нужно изолировать "прожорливого соседа" - то есть виртуальную машину, которая может начать потреблять несоразмерно много ресурсов хранилища по вводу-выводу на хосте ESXi, вызывая большие задержки (latency) у других машин этого хоста. При этом такая машина на данном хосте может быть далеко не самой важной.

Ограничение машины по IOPS имеет некоторые особенности. Размер операции ввода-вывода может варьироваться в диапазоне от 4 КБ до 1 МБ. Это означает, что самая большая операция может быть в 256 больше по объему самой маленькой. Поэтому при применении ограничения по IOPS решение vSAN использует так называемые "взвешенные IOPS", определяемые квантами по 32 КБ (об этом мы писали вот тут). При размере операции до 32 КБ планировщик vSAN считает ее как одну операцию, 32-64 КБ - как две, и так далее.

Это позволяет при визуализации метрик производительности нормализовать поток данных к хранилищу и управлять им при импорте настроек из механизма SIOC, который применяется к виртуальным машинам не в кластере vSAN. Надо отметить, что vSAN имеет собственную механику регуляции I/O и собственный планировщик, поэтому механизм SIOC не применяется к таким хранилищам.

Соответственно, давайте взглянем на графики операций ввода-вывода на вкладке Monitor->vSAN->Performance:

На нижнем графике (Virtual SCSI IOPS) мы видим число реальных операций ввода-вывода, независимо от их размера, а на верхнем - уже нормализованные IOPS и лимиты, применяемые к ВМ.

IOPS limit применяется только ко всему потоку ввода-вывода гостевой ОС машины (то есть ярус хранения, ярус кэширования), но не затрагивает операции с самим диском VMDK и его swap-файлами, например, репликация машины, SVmotion (миграция хранилища), XVmotion (миграция машин без общего хранилища) и клонирование ВМ.

Если машина достигает лимита по IOPS, планировщик vSAN для нее начинает откладывать операции ввода-вывода до завершения транзакции таким образом, чтобы они не превышали заданного лимита по нормализованному числу операций в секунду. Это все приводит к тому, что задержки исполнения данных операций (latency) существенно возрастают, что видно на графике Virtual SCSI Latency:

Здесь мы видим, что при достижении лимита 200 IOPS latency возросла до 580 мс, а при достижении 400 мс - где-то до 230-290 мс. Эти задержки, возникающие на уровне виртуальной машины, проявляют себя также и на уровне всего хоста, кластера и даже приложений, таких как vRealize Operations.

Этот важный фактор надо учитывать, когда вы ищете причину высокой latency, потому что механизм vSAN Performance Service не делает различий, возникли ли задержки из-за проблем с производительностью, или они являются результатом применения IOPS limits.

Интересно также, что применение IOPS limits storage policy rule к одной виртуальной машине может повлиять и на другую ВМ, к которой не применяется этого правила. Например, вы копируете файлы одной ВМ на вторую (и обратно), у которой есть IOPS limit. При достижении этого лимита, очевидно, происходит уменьшение числа IOPS не только у целевой ВМ, но и у источника, так как происходит уменьшение совокупного числа операций ввода-вывода на передачу файлов.

При этом у исходной ВМ в этом случае не будет существенного изменения latency, так как ее операции откладываться не будут (посмотрите на левый и правый графики этой ВМ):

К сожалению, описанные эффекты влияния на производительность ВМ не всегда просто идентифицировать, поэтому нужно всегда осторожно выставлять IOPS limit и всегда четко его документировать в описании конфигурации виртуальной инфраструктуры.

В середине января мы писали о первом в этом году обновлении VMware vSphere Client 4.0 - официальном клиенте vSphere на базе технологии HTML5. На днях компания VMware на сайте проекта Labs выпустила новую версию vSphere Client 4.1, которая уже доступна для загрузки.

Давайте посмотрим, что нового появилось в тонком клиенте vSphere версии 4.1:

• Обратно была добавлена поддержка VMware vCenter 6.0, которая пропала в прошлой версии. Теперь в качестве серверов vCenter поддерживаются версии 4.1 - 6.0, 6.5 и 6.7.
• Возможность спрятать виртуальные машины в представлении Hosts and Clusters. Эта фича пришла с десктопных клиентов (Workstation и Fusion), она позволяет убрать ВМ, чтобы они визуально не засоряли консоль (делается это через My preferences -> Inventory).
• Настройки My preferences теперь содержат дополнительные опции, такие как язык, временная зона, параметры консоли и инвентори.
• В Developer Center теперь есть вкладка API Explorer, на которой есть список всех REST API, предоставляемых vSphere SDK.
• Новая компоновка элементов feedback tool. Кроме того, теперь можно можно делать скриншот клиента, даже когда открыты модальные диалоговые окна. Также feedback tool теперь имеет возможности по добавлению скриншотов, что позволяет сравнить фичи между различными версиями клиентов.
• Нотификация об устаревании лицензии теперь показывает 90 дней вместо 60.
• Лицензия Evaluation License теперь отображается в списке лицензий. Сам же список теперь сортируется по дате устаревания лицензий.

Скачать VMware vSphere Client 4.1 можно по этой ссылке.

Недавно VMware объявила о большом обновлении своего решения для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker - VMware NSX-T 2.4 (кстати, вот видео об отличии этого решения от NSX-V для vSphere).

Это уже пятое обновление данной платформы, при этом для компании это большой анонс, так как продукт существенно расширяет возможности по обеспечению сетевой управляемости гибридных (облачных и онпремизных) инфраструктур и обеспечивает полную поддержку протокола IPv6.

Напомним, что прошлая версия NSX-T 2.3 вышла в сентябре прошлого года. С тех пор многое изменилось, поэтому давайте посмотрим, что нового (из основного) появилось в NSX-T 2.4:

1. Упрощение установки, конфигурации и ежедневного оперирования.

В этой области появилось 3 основных улучшения:

• Новый виртуальный модуль NSX manager appliance, который поддерживает кластерную конфигурацию до 3 узлов, каждый из которых выполняет функции обеспечения политик и контроля сетевой инфраструктуры. Это дает высокий уровень отказоустойчивости. Также установщик имеет модули Ansible для упрощения процедуры автоматизированной установки и настройки рабочих процессов.
• Радикально упрощенный пользовательский интерфейс, где еще более продуманы значения по умолчанию и уменьшено число экранов и кликов для ежедневных операций.
• Контекстный поиск с мощными функциями по автозаполнению, что упрощает решение проблем из консоли NSX-T.

Вот в качестве примера окно обзора конфигураций - видно, насколько все стало более наглядным и удобным для восприятия:

2. Декларативная модель политик.

Эта новая модель распространения конфигураций и настроек безопасности позволяет пользователю определить, что необходимо для обеспечения связности и безопасности, вместо того, чтобы задавать, как нужно пройти по шагам процесс настройки.

Вместо детализированных вызовов API, которые должны быть выполнены в строго определенной последовательности, NSX Manager теперь принимает на вход декларативное описание политики в виде одной API команды с данными в формате JSON, которое несложно понять (а значит, увеличивается прозрачность операций).

Также такой подход уменьшает число вероятных ошибок, связанных с последовательностью или полнотой команд API. К тому же, он позволяет легко переносить описание политики для приложения между платформами. В видео ниже показан реальный пример использования таких декларативных политик (с семнадцатой минуты):

3. Расширенные возможности безопасности.

Новый релиз NSX продолжает развивать концепцию микросегментации приложений. В этом направлении появились следующие новые возможности:

• Контекстный сетевой экран, работающий на уровне 7 модели OSI.

• Фаервол на базе сетевой идентичности приложения.
• Белые списки адресов FQDN/URL на распределенном фаерволе (DFW) для разрешения определенного типа трафика ВМ к определенным адресам или хостам в датацентре:

• Возможность анализа трафика на уровне гостевой ОС (guest introspection).
• Возможности E-W service insertion (контроль трафика в пределах датацентра средствами сторонних IDS/IPS-систем).

Также в NSX-T 2.4 существенно был улучшен механизм аналитики и визуализации данных, а также появилась поддержка Splunk и VMware vRealize Log Insight.

Ну а о новых возможностях обеспечения сетевой безопасности можно узнать из этого видео:

4. Высокий уровень масштабируемости, надежности и производительности.

Прежде всего, в рамках новых возможностей в этой категории, у NXS-T появилась полноценная поддержка протокола IPv6. Кластер NSX-T теперь состоит из 3 полноценных и равноправных узлов, что дает расширенные возможности по масштабированию решения и обеспечению надежности.

В одном NSX-домене теперь может быть более 1000 хостов с полной поддержкой разделения сетевой инфраструктуры между различными клиентами уровня виртуального датацентра.

5. Партнерства и новые возможности для пользователей.

Со стороны NSX-T поддержка продуктовой линейки VMware и партнерских решений была существенно расширена. Теперь такие решения, как Kubernetes, VMware PKS, Pivotal Application Service (PAS) и Red Hat OpenShift в различной мере поддерживаются NSX-T, и их поддержка будет только расширяться.

Конечно же, обеспечивается поддержка облачных решений, особенно VMware Cloud on AWS и нативных облачных нагрузок через VMware NSX Cloud. Также продукт NSX-T включен в состав таких платформ, как VMware Cloud Foundation, VMware vCloud NFV, а в будущем и в AWS Outposts и VMware Cloud Foundation for EC2.

Более подробно о новых возможностях VMware NSX-T 2.4 рассказано в Release Notes. Скачать продукт можно по этой ссылке. Вот еще несколько полезных ресурсов:

• NSX Hands-On-Lab (HOL)
• Канал по NSX на YouTube
• Документация

На днях компания VMware выпустила первое в этом году обновление своего фреймворка для управления виртуальной инфраструктурой PowerCLI 11.2.0. Напомним, что о прошлом обновлении - PowerCLI 11.1 - мы писали вот тут.

Давайте посмотрим, что нового появилось в обновлении PowerCLI 11.2:

Новый модуль для VMware HCX.

Решение VMware HCX - это набор утилит для управления гибридной средой, состоящей из ресурсов облака и онпремизной инфраструктуры. С помощью нового модуля для HCX вы можете выполнять миграции vMotion (в том числе, в пакетном режиме), включая очень большие ВМ, поддерживать жизненный цикл ВМ, а также защищать данные в целях катастрофоустойчивости, дублирование которых происходит на уровне площадок.

Всего здесь было добавлено 20 командлетов, решающих подобные проблемы. Более подробно о них можно почитать вот тут.

Добавлена поддержка служб NSX-T Policy services.

Решение NSX-T позволяет абстрагировать управление сетями и безопасностью сетевой инфраструктуры датацентра с помощью политик. Также NSX-T применяется для обеспечения доступности сервисов.

За счет нового командлета Get-NsxtPolicyService теперь можно автоматизировать большинство операций по управлению политиками, используя стандартный API. Командлет совместим с недавно анонсированной новой версией решения NSX-T 2.4.

Добавлена поддержка служб OAuth для соединения с vCenter.

В плане поддержки инфраструктуры безопасности VMware Cloud on AWS, в новой версии PowerCLI был существенно доработан механизм аутентификации. Теперь появилось 2 новых командлета для аутентификации и обновился существующий командлет для поддержки механизма OAuth2.

Для облачного модуля VMC появился специальный командлет New-VcsOAuthSecurityContext, который позволяет использовать контекст безопасности сессии работы пользователя на базе токена VMware Cloud on AWS

Для модуля Core появился командлет New-VISamlSecurityContext, который позволяет получить и использовать контекст безопасности OAuth и транслировать его в контекст SAML2, который уже используется для соединения с vCenter (Connect-VIServer) и прочего.

Передача контекста выглядит следующим образом:

$oauthCtx = New-VcsOAuthSecurityContext -ApiToken "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

$samlCtx = New-VISamlSecurityContext -VCenterServer "vcsa.fqdn" -OAuthSecurityContext $oauthCtx

Connect-VIServer -SamlSecurityContext $samlCtx

Поддержка Opaque Networks (сетей виртуальной инфраструктуры, которые управляются извне решения vSphere, например, OpenStack).

С помощью командлетов Set-NetworkAdapter и Import-VApp можно организовать поддержку сетей Opaque Networks. Более подробно об этом можно почитать в статье Configuring VMs For Opaque Networks.

Обновленные командлеты модуля Storage.

Командлет Get-VsanSpaceUsage теперь имеет новый параметр, который позволяет возвращать результаты по определенной политике хранилищ.

Также в командлет добавили несколько параметров от командлета Set-VsanClusterConfiguration (CustomizedSwapObjectEnabled, GuestTrimUnmap, LargeClusterSupported, ObjectRepairTimerMinutes и SiteReadLocalityEnabled). Обновился и командлет Test-VsanNetworkPerformance, который теперь имеет параметр DurationInSecond (с помощью него можно регулировать время тестирования производительности хранилища).

Посмотреть историю изменений VMware PowerCLI 11.2.0 можно по этой ссылке. Документация доступна тут. Если вы что-то забыли, то всегда можно воспользоваться справочником по PowerCLI - VMware PowerCLI 11.2.0 Cmdlet Reference.

Напомним, что обновить актуальную версию PowerCLI на обновление версии 11.2, можно использовать команду:

Update-Module VMware.PowerCLI

Еще на конференции VMworld 2018 компания VMware анонсировала инициативу по использованию в качестве инфраструктуры блочных хранилищ сервисов Amazon Elastic Block Store (называлось это EBS backed vSAN). Несколько позднее это оформилось в виде технологии VMware Elastic vSAN, которая будет доступна в ближайшем будущем.

Изначально сервис VMware vCloud on AWS, предоставляющий виртуальную инфраструктуру виртуальных машин в аренду из облака Amazon, использовал инстансы I3.Metal в облаке EC2. Но для некоторых пользователей, имеющих существенные объемы данных, масштабирование за счет только увеличения числа инстансов в кластере не подходило - столько вычислительных ресурсов не требовалось, а требования к объему дискового пространства упирались в физические возможности хостов (10 ТБ на инстанс I3.Metal).

Поэтому VMware предложила другое решение - сделать хранилище инфраструктуры vSphere в облаке внешним, взяв за основу инстанс R5.Metal и подключив к нему масштабируемое облачное хранилище Elastic Block Store (EBS):

При создании бездисковых хостов Elastic vSAN пользователь указывает объем хранилища на хост (от 15 до 35 ТБ с шагом 5 ТБ), который требуется для кластера виртуальной инфраструктуры хранилищ, и она достраивается из компонентов блочного пространства EBS.

Когда технология Elastic vSAN включена, каждый хост имеет 3 дисковых группы, а каждая группа имеет от 3 до 7 дисков полезной емкости (помимо кэш-дисков):

Для такой конфигурации, чтобы обеспечить политику Failures to Tolerate = 1, рекомендуется включать RAID-5 (для этого нужно минимально 4 узла) и настройку "Compression only mode" для экономии дискового пространства. В этом случае не потребуется включать дедупликацию (она и недоступна в целях обеспечения высокой производительности), компрессии будет достаточно.

Все это дает возможность использовать меньшее число хостов, чем в случае с I3.Metal, что особенно полезно для нагрузок, которым не требуется много вычислительных ресурсов, но требуется много хранилища (например, файловые помойки). Это дает 140 ТБ сырой емкости на 4-узловой кластер и 560 ТБ на 16 узлов. Этого должно хватить практически всем.

Также при использовании I3.Metal или онпремизного кластера vSAN, в ситуации с эвакуацией виртуальных машин хоста для целей обслуживания, приходилось переносить все его содержимое на другой инстанс, что занимало значительное время. Для бездисковых инстансов R5.Metal получается так, что в случае выведения хоста из эксплуатации его хранилища на стороне EBS можно за небольшое время просто переподключить к новому инстансу - это и будет миграцией хоста без физического переноса данных.

Помимо упрощения обслуживания, такая архитектура дает еще несколько возможностей по построению гибких решений, в которых можно внедрять новые фичи Elastic vSAN быстрее, чем в онпремизных решениях. Заявлено, что новая архитектура будет выдавать до 10K IOPS на устройство/том (вне зависимости от его размера, минимальный размер 3 ТБ) и пропускную способность до 160 Мбит/с.

Обо всех будущих новых возможностях VMware vCloud on AWS вы можете узнавать на специальной странице. Ну и рекомендуем посмотреть запись сессии об Elastic vSAN с VMworld 2018 (там есть еще и интересная презентация в PDF).

Гостевой пост нашего партнера, IaaS-провайдера - компании ИТ-ГРАД. Технология vSAN является одним из элементов гиперконвергентной системы от VMware, которую активно используют облачные провайдеры для создания отказоустойчивой, гибкой и масштабируемой услуги по аренде виртуальной инфраструктуры (IaaS). Но прежде чем приступить к обсуждению данной технологии...

Одна из новых возможностей, анонсированных в платформе виртуализации VMware vSphere 6.7 - это vSphere Health. О ней мы уже вкратце упоминали вот тут.

Сегодня мы дополним эту информацию. Механизм vSphere Health опирается на глобальную базу знаний VMware, которая позволяет ежедневно выдавать предупреждения о 100 тысячах потенциальных проблем в инфраструктурах заказчиков и решать около 1000 актуальных проблем каждый день.

На данных момент vSphere Health включает в себя около 30 проверок (Heath Checks), которые запускаются для окружения vSphere. Вот примеры проблем, которые могут подсвечивать данные проверки:

• Утечка памяти в драйвере bnx2x
• Хост ESXi, использующий Intel Controller X710 для сетевого адаптера 10GbE SFP+ вываливается в "розовый экран" (PSOD).
• Ошибка L1 Terminal Fault (L1TF – VMM) - уязвимость типа Speculative-Execution в процессорах Intel.
• Хост ESXi 6.5 вываливается в PSOD при отключенном IPV6.

Для фиксирования, аналитики и поиска решений подобных проблем компания VMware использует облако VMware Analytics Cloud (VAC), которое принимает данные телеметрии виртуальных инфраструктур (онпремизных и SaaS-приложений) и формирует рекомендации по решению проблем. Сами данные в обезличенном виде передаются с помощью движка Customer Experience Improvement Program (CEIP).

Облако VAC постоянно анализирует пользовательские виртуальные среды, при этом оно постоянно пополняется новыми знаниями о проблемах, которые в асинхронном режиме отображаются в интерфейсе пользователей в vSphere Client (для vSphere 6.7 и более поздних версий).

Данные инфраструктур заказчиков, которые попадают в облако VAC через механизм CEIP, надежно защищаются. Их использование людьми доступно только для выполнения определенных задач. Сами правила регулируются комитетом Product Analytics Data Governance Board, куда входят инженеры, юристы, специалисты по безопасности и прочие сотрудники с различными ролями. Эта команда регулярно проверяет рабочий процесс использования этих данных. Естественно, эти данные не передаются третьим сторонам.

О том, какие именно данные собираются с помощью CEIP, и как они используются, можно почитать в специальном документе (он небольшой, 10 страниц). Включить CEIP можно через интерфейс vSphere Client следующим образом:

Также этот механизм можно включить при апгрейде платформы vSphere или через интерфейс командной строки (CLI). В рамках CEIP собирается следующая информация о виртуальной среде:

• Configuration Data – как и что у вас настроено в плане продуктов и сервисов VMware.
• Feature Usage Data - как именно вы используете возможности продуктов и сервисов.
• Performance Data - производительность различных объектов виртуальной инфраструктуры в виде метрик и чсиленных значений (отклик интерфейса, детали об API-вызовах и прочее).

Если в рамках вашего плана поддержки вы используете Enhanced Support для CEIP (например, Skyline), то на серверы VMware для анализа отправляются еще и продуктовые логи (Product Logs). Документация по CIEP доступна здесь.

Чтобы посмотреть текущие проверки Health Checks, нужно перейти на вкладку Monitor сервера vCenter Server, после чего перейти в раздел Health:

Там видны проблемы и объекты, к которым они относятся (в данном случае, к хостам ESXi):

Завтра мы расскажем подробнее о том, как работают эти проверки, какие решения они предлагают, и как помогают администратору держать виртуальную инфраструктуру в порядке.

В конце прошлого года мы писали о новых возможностях VMware vCenter в составе обновленной платформы виртуализации VMware vSphere 6.7 Update 1. Среди прочих интересных фичей, vCenter 6.7 U1 получил функцию Health Сhecks, которая позволяет обрабатывать данные телеметрии виртуальной инфраструктуры и на основе экспертных алгоритмов вырабатывать рекомендации по ее улучшению. Например, если у вас одна сеть Management network, вам могут порекомендовать ее задублировать.

Вчера мы писали об общем устройстве механизма vSphere Health. Давайте теперь детально посмотрим, как именно это работает. Сделано это чем-то похоже на службы vSAN Health Services, но здесь больше проактивной составляющей (то есть рекомендации генерируются постепенно и еще до возникновения реальных проблем).

Для просмотра основных хэлсчеков сервера vCenter, нужно в vSphere Client пойти на вкладку Monitor и выбрать там раздел Health:

Чтобы эти фичи функционировали корректно, нужно чтобы у вас была включена настройка Customer experience improvement program (CEIP). Если вы не включили ее во время установки vCenter, то вы всегда можете сделать это в разделе Administration клиента vSphere Client:

Надо отметить, что vCenter Health Сhecks не только оповещает о проблемах виртуальной инфраструктуры, но и в некоторых случаях предоставляет ссылки на статьи базы знаний VMware KB, которые могут помочь найти решения.

Если вы нажмете на какой-нибудь из ворнингов, например, "Disk space check for VMware vCenter Server Appliance", то увидите две группы параметров на вкладках "Details" и "Info":

На вкладке Details отображены численные значения и/или объекты виртуальной инфраструктуры, имеющие отношение к предупреждению, а вот вкладка Info разъясняет его суть и дает рекомендации по его устранению. Если же в правом верхнем углу появился значок "Ask VMware", значит для данного предупреждения есть ссылка на статью базы знаний VMware KB, которая может помочь:

Например, здесь на двух из трех хостов ESXi установлена не последняя версия драйвера bnx2x (адаптер Broadcom NetXtreme II 10Gb):

На вкладке Info объясняется, что хосты с такой версией драйвера этого устройства могут вывалиться в "розовый экран":

Если нажмем "Ask VMware", то в новой вкладке откроется статья KB, описывающая проблемы данной версии драйвера и пути их решения:

Если вы сделали изменения конфигурации согласно рекомендациям, вы можете нажать кнопку RETEST в правом верхнем углу, чтобы увидеть только актуальные предупреждения:

Некоторые администраторы инфраструктуры VMware vSphere знают, что существует средство Update Manager Download Service (UMDS), с помощью которого можно скачивать обновления ESXi для последующего их наката со стороны vSphere Update Manager (VUM), интерфейс которого сейчас реализован в vSphere Client на базе HTML5:

UMDS вам может оказаться полезным в двух случаях:

• Вы не можете выставить в интернет сервер vCenter, частью которого является VUM, для загрузки обновлений (например, в соответствии с корпоративными политиками). Поэтому нужно развернуть UMDS на компьютере в DMZ, с которого VUM будет забирать обновления (либо вы будете их перекидывать на VUM вручную).
• У вас есть несколько серверов Update Manager, и вы используете UMDS в качестве централизованной точки распространения обновлений серверов ESXi, чтобы каждый vCenter не скачивал обновления из интернета самостоятельно.

Начиная с Update Manager версии 6.7, сервис UMDS доступен для развертывания на платформах Windows и Linux. Для Windows поддерживаются те же серверные ОС, что и для сервера vCenter, а для Linux список систем можно найти в документации. Вот они:

• Ubuntu 14.0.4
• Ubuntu 18.04
• Red Hat Enterprise Linux 7.4
• Red Hat Enterprise Linux 7.5

Кстати, начиная с vSphere 6.7 Update 1, VMware отменила требование к созданию базы данных для UMDS, поэтому использование сервиса стало еще проще и удобнее.

Если вы используете UMDS на Windows, то вам понадобится Microsoft .NET framework 4.7 и та же версия UMDS, что и сам Update Manager.

На Linux UMDS автоматически не создает переменной PATH для сервиса vmware-umds. Чтобы запустить команду vmware-umds нативно, нужно добавить переменную окружения с путем к сервису следующей командой:

PATH=”$PATH”:/usr/local/vmware-umds/bin

Чтобы на Linux посмотреть текущую конфигурацию UMDS, нужно выполнить команду:

/usr/local/vmware-umds/bin/vmware-umds -G

Здесь мы видим сконфигурированные урлы для хранилищ обновлений (depots), локальный путь к хранению патчей и путь экспорта хранилища, по которому серверы VUM будут забирать обновления. Также здесь мы видим, контент каких версий ESXi нужно скачивать.

Если у вас все хост-серверы одной версии, например, ESXi 6.7, то вы можете отключить скачивание всех остальных образов командой:

sudo ./usr/local/vmware-umds/bin/vmware-umds -S -d embeddedEsx-6.0.0 embeddedEsx-6.5.0 embeddedEsx-6.6.1 embeddedEsx-6.6.2 embeddedEsx-6.6.3

Еще одна важная опция - это задание собственного пути к репозиторию обновлений. Например, если вы используете кастомизированные образы ESXi для серверов Dell, то вы можете добавить адрес репозитория следующей командой:

sudo ./usr/local/vmware-umds/bin/vmware-umds -S --add-url http://vmwaredepot.dell.com/index.xml --url-type HOST

После того, как URL репозитория добавлен, мы можем принудительно скачать все образы обновлений командой:

sudo /usr/local/vmware-umds/bin/vmware-umds -D

Полный список опций UMDS можно получить с помощью вот этой команды:

/usr/local/vmware-umds/bin/vmware-umds --help

Далее вам нужно уже пойти на сервер VMware Update Manager и настроить его на использование с репозиторием UMDS. Если у вас очень высокие требования к безопасности, то вы можете отнести обновления на сервер VUM, например, на флешке. Второй вариант - настроить на UMDS веб-сервер и указать его как путь для обновлений от VUM.

Если вы используете вариант с веб-сервером, то его публичную папку надо настроить на следующий путь по умолчанию:

• C:\ProgramData\VMware\VMware Update Manager\Data\ - на Windows.
• /var/lib/vmware-umds - на Linux.

Некоторые из вас, возможно, слышали об утилите vCheck for Horizon (vCheck-HorizonView), которая позволяет вам на регулярной основе готовить отчеты о текущем состоянии инфраструктуры виртуальных ПК VMware Horizon View. Этот проект базируется на утилите vCheck для VMware vSphere, которая развивается уже почти 7 лет.

В новой версии vCheck for Horizon появились следующие новые возможности:

1. Проверки состояния инфраструктуры ферм RDS:

2. Проверки состояния домена Active Directory:

3. Вызов vCenter API был разделен на 3 части - состояние сервиса vCenter, статус хостов ESXi и состояния подключенных датасторов:

4. Также была добавлена проверка работоспособности механизмов saml и truesso.

Скачать vCheck for Horizon можно по этой ссылке, а пример итогового отчета в формате HTML можно посмотреть вот тут.

Недавно компания VMware объявила о выпуске бета-версии сервиса VMware Automated Virtual Assistant (AVA) - виртуального помощника, который может вам подсобить с поиском документации о продуктах VMware. Этот помощник предоставляется в виде чат-бота, который можно использовать посредством языка естественных запросов NLP (natural language processing). Он агрегирует знания из документации по vSphere, Horizon, vSAN и всем прочим продуктам, а также имеет ответы на соответствующие FAQs, которые есть по практически всем решениям VMware.

Например, вот таким образом можно спросить о документации, касающейся производительности виртуальных процессоров машин (vCPU) на платформе VMware vSphere 6.5:

Для активации помощника VMware AVA нужно просто зайти на сайт VMware Docs и вызвать всплывающее окно с любой страницы.

Пока AVA находится в режиме Training Mode - это означает, что движок еще проходит стадию обучения, и вы можете помочь ему корректно отвечать на вопросы своей обратной связью (для этого предусмотрен соответствующий функционал - например, пометить, какой из предложенных вариантов оказался лучшим). Это позволит объединить похожие запросы и выдавать более релевантные результаты в будущем.

Помимо запросов к документации и часто задаваемым вопросам, вы можете поделиться с AVA своей проблемой (конечно же, касательно виртуальной инфраструктуры:) - и она попытается найти решение.

Кстати, обратите внимание, что на картинке выше показано, что AVA помнит контекст беседы. Она запомнила, что речь будет идти о платформе vSphere версии 6.5, и все дальнейшие вопросы она будет воспринимать как относящиеся именно к этому продукту.

Пока Automated Virtual Assistant доступен только на английском языке, но обещают и поддержку других языков. Однако, как мы знаем, VMware не очень жалует русский, поэтому не стоит ждать его поддержки, по крайней мере, в ближайшем будущем. А так AVA - штука весьма интересная.

На сайте проекта VMware Labs появилась интересная и полезная некоторым администраторам vSphere штука - USB Network Native Driver for ESXi. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.

Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).

На данный момент драйвер поддерживает 3 самых популярных чипсета на рынке:

• ASIX USB 2.0 gigabit network ASIX88178a
• ASIX USB 3.0 gigabit network ASIX88179
• Realtek USB 3.0 gigabit network RTL8153

А вот, собственно, и сами поддерживаемые адаптеры:

Надо отметить, что это сравнительно недорогие устройства, которые может позволить себе каждый администратор платформы vSphere.

Установка драйвера производится одной командой:

esxcli software vib install -d /path/to/the offline bundle

Затем нужно будет перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0. Но чтобы приаттачить такой NIC к виртуальному коммутатору vSwitch, придется добавить в /etc/rc.local.d/local.sh такой скрипт:

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

  count=0

  while [[ $count -lt 20 && "${vusb0_status}" != "Up" ]] ]

  do

sleep 10

count=$(( $count + 1 ))

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

done

if [ "${vusb0_status}" = "Up" ]; then

  esxcfg-vswitch -L vusb0 vSwitch0

  esxcfg-vswitch -M vusb0 -p "Management Network" vSwitch0

  esxcfg-vswitch -M vusb0 -p "VM Network" vSwitch0

  fi

Драйвер работает с VMware vSphere 6.5 и 6.7. Скачать его можно по этой ссылке.

Продолжаем рассказывать о новых возможностях следующей версии решения для создания отказоустойчивых кластеров хранилищ VMware vSAN. Напомним прошлые статьи этого цикла:

• Что нового будет в VMware vSAN следующей версии, часть 2: поддержка First Class Disk (FCD)
• Анонсы VMworld Europe 2018, часть 3 - технология VMware vSAN Native Data Protection (первая статья серии)

В этой заметке мы поговорим еще об одной возможности, касающейся способов хранения данных в кластере - vSAN Scalable File Services. Как вы знаете, vSAN предоставляет пространство хранения для виртуальных машин и дисков VMDK (в том числе дисков FCD), а также дает возможность использовать логические тома по протоколу iSCSI.

Так вот, функциональность vSAN File Services дает возможность использовать дисковое пространство по протоколам NFS и SMB, что дает возможность раздавать ресурсы кластера через эти протоколы для внешних потребителей без необходимости создания отдельных машин для файловых помоек, например, с Windows Server на борту.

Также файловые шары NFS/SMB будут находиться под управлением политик Storage Policy Based Management (SPBM), а также будут работать в растянутых кластерах vSAN, что позволит рассматривать их как часть общего пространства vSAN в распределенных датацентрах. С помощью SPBM можно будет использовать такие сервисы, как FTT (переносимость отказов хостов ESXi), шифрование и развертывание хранилищ, растущих по мере наполнения данными (thin provisioning).

Механизм файлового шаринга работает на базе файловой системы vSAN Distributed File System (vDFS), которая позволяет агрегировать дисковые объекты vSAN для предоставления пространства хранения, а сервисы управления предоставляет платформа Storage Services Platform.

С точки зрения интерфейса создания и экспорта файловых шар, эти сервисы будет представлять vCenter и vSphere Client (там же будут назначаться права доступа, квоты и прочее).

Сервисы vSAN FIle Server (в демо они были показаны как виртуальные модули, Virtual Appliances) будут реализовывать экспорт папок. Кроме того, они будут иметь механизм обнаружения сбоев и перезапуска этих машин на других серверах:

Такая архитектура также позволит просто апгрейдить хост-серверы ESXi, не останавливая предоставляемые файловые сервисы.

Кроме того, vSAN File Services будут предоставлять свои ресурсы на уровне файлов для контейнеров на платформе Kubernetes:

Также вы можете посмотреть 2 интересных видеопрезентации с VMworld 2018 и VMworld Europe 2018, посвященных vSAN Scalable File Services:

• HCI3041BE – VMworld Europe 2018 session: Introducing Scalable File Storage on vSAN with Native File Services. Также к этому видео прилагается презентация в формате PDF.

• HCI3728KE – VMworld Europe 2018 session:  Innovating Beyond HCI: How VMware is Driving the Next Data Center Revolution.

Подписаться на бету следующей версии продукта VMware vSAN можно по этой ссылке. Ожидается, что первая реализация будет поддерживать NFS 4.1 с аутентификацией в AD, шары SMB, Kerberos, протокол OpenLDAP и механизм vSAN Data Protection.

Больше пяти лет назад мы писали про проект vCenter Server Simulator 2.0 (VCSIM), который позволял протестировать основные интерфейсы VMware vCenter без необходимости его реального развертывания (а значит и без лицензии). Проблема в том, что он был выпущен для VMware vSphere и vCenter версий 5.5 и с тех пор не обновлялся.

Зато есть аналог старому VCSIM - новый проект govcsim, написанный на языке Go (Golang). Он точно так же умеет предоставлять API-ответы на вызовы к vCenter Server и ESXi.

Несмотря на то, что этот симулятор написан на Go, он позволяет вам работать с vCenter посредством любого языка и интерфейса, умеющего общаться через API (в том числе, PowerShell). То есть, вы можете соединиться через PowerCLI к VCSIM Docker Container и работать с ним как с сервером vCenter.

Сам контейнер nimmis/vcsim можно скачать отсюда. Pull-команда для него:

docker pull nimmis/vcsim

Далее можно выполнить вот такой сценарий (взято у Brian Bunke):

docker run --rm -d -p 443:443/tcp nimmis/vcsim:latest

If ($IsMacOS -or $IsLinux) {

$Server = 'localhost'

} Else {

$Server = (Get-NetIPAddress -InterfaceAlias *docker* -AddressFamily IPv4).IPAddress

}
If ($PSVersionTable.PSVersion.Major -ge 6) {

Test-Connection $Server -TCPPort 443

}
Connect-VIServer -Server $Server -Port 443 -User u -Password p

# Did it work?

Get-VM

# Or Get-VMHost, or Get-Datastore, etc.

Этот код делает следующее:

• Запускает docker-контейнер VCSIM локально (если у вас его нет, то он будет загружен).
• На Windows-системе получает IP-адрес адаптера DockerNAT.
• После запуска контейнера тестирует, что порт 443 отвечает.
• Использует модуль VMware.PowerCLI интерфейса PowerShell для соединения с vCenter Simulator.

Симулятор на данный момент поддерживает не все множество API-методов (смотрите документацию). Вот так, например, можно вывести список всех поддерживаемых методов и типов:

$About = Invoke-RestMethod -Uri "https://$($Server):443/about" -Method Get

$About.Methods

$About.Types

Например, вы можете использовать PowerOffVM_Task, PowerOnMultiVM_Task и PowerOnVM_Task. Из PowerCLI попробуйте также протестировать командлеты Stop-VM и Start-VM. Ну а дальше изучайте документацию к библиотеке govmomi.

Во время прошедшего летом прошлого года VMworld 2018 компания VMware представила много интересных новостей на тему будущей функциональности продукта для создания отказоустойчивых хранилищ VMware vSAN. Например, мы писали о технологии Native Data Protection (это часть 1 этого цикла статей), а сегодня поговорим о сервисах хранения.

Диски First Class Disk (FCD)

Для vSAN уже есть поддержка так называемых дисков First Class Disk (FCD), они же называются Improved Virtual Disk (IVDs) или Managed Virtual Disk. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.

К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes (он называется vSphere Cloud Provider) для создания постоянных (persistent) томов контейнеров Docker. Этим всем занимается опенсорсный проект Project Hatchway от VMware.

Работать с такими дисками очень неудобно - для них приходится создавать отдельную виртуальную машину к которой цепляется этот диск, а потом, по завершении какого-либо процесса, отсоединяется, и машина уничтожается. Так, например, работает средство для резервного копирования App Volumes Backup Utility, о котором мы писали вот тут. При бэкапе этих дисков создается временная Backup VM:

Второй пример - инфраструктура vSphere Integrated OpenStack (VIO), где для того, чтобы включить хранилище Cinder (OpenStack Block Storage) для потребления дисковой емкости VMDK-файлов, нужно создавать вспомогательные Shadow VM для каждого тома Cinder, к которому цепляется VMDK-диск.

Все это неудобно, поэтому и придумали формат дисков First Class Disk (FCD), которому не требуются временные виртуальные машины и которые реализуют сервисы, необходимые приложениям или другим сервисам. Например, бэкап таких дисков можно делать без создания вспомогательной ВМ.

Информация о дисках FCD хранится в каталоге базы данных vCenter. Она содержит глобальные уникальные идентификаторы UUID и имена дисков. UUID позволяет переместить диск в любое место без конфликтов.

Впервые API для работы с FCD появился в VMware vSphere 6.5, например, вот хороший пост от Вильяма Лама об этом. Но в этом релизе было ограничение на резервное копирование FCD-дисков, которые не присоединены к ВМ (в качестве workaround приходилось все же использовать Dummy VM).

В vSphere 6.7 это ограничение было снято, но остались еще некоторые требования - FCD нужно было восстанавливать с тем же UUID и на тот же датастор, откуда он был взят. Также еще одним ограничением была невозможность API отслеживать блоки, изменившиеся с момента последней резервной копии, то есть невозможность инкрементального резервного копирования (подробнее здесь).

Ну а в vSphere 6.7 Update 1 была анонсирована ограниченная поддержка FCD для vSAN. Пока поддержка предоставляется еще с ограничениями для служб health service и capacity monitoring. Однако при этом пользователи Kubernetes могут использовать диски FCD на хранилищах vSAN для персистентных хранилищ контейнеров, и в то же самое время тома vSAN могут использоваться для виртуальных машин:

Подписаться на бету следующей версии продукта VMware vSAN можно по этой ссылке.

В следующей статье мы расскажем про Cloud Native Storage (CNS) и vSAN File Services.

Давайте для начала разберёмся с терминологией. Что такое роли NSX-менеджера? Роли NSX-менеджера позволяют управлять правами доступа к объектам NSX с помощью присвоения той или иной роли отдельному пользователю или группе. В UI эти настройки находятся в Networking & Security -> System -> Users and Domains.

Компания StarWind, ведущий производитель решений для создания отказоустойчивых программных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, приглашает на бесплатный вебинар "Building a stretched cluster: Keep your data always secure".

Вебинар пройдет 7 февраля в 22-00 по московскому времени.

На мероприятии Алексей расскажет обо всех нюансах развертывания географически "растянутого" кластера для виртуальных машин в части хранилищ. В рамках вебинара будет рассказано, как построить такой кластер, каким аспектам отказоустойчивости (HA) уделить особое внимание, и какие меры необходимо принять в целях обеспечения безопасности такой среды. Ну и, конечно же, Алексей расскажет о том, как предотвратить ситуацию Split Brain в таких сценариях.

Регистрируйтесь бесплатно!